This invention relates to an emulator for multi-processes, more specifically to a device for supporting the testing of software, and in particular to an emulator for multi-processes and an emulation method, which are suitable for the testing of software under a multi-process environment.
In the case where a system, in which a microprocessor of 32 or 16 bits is incorporated, is tested, an in-circuit emulator (hereinbelow called simply emulator) is used often. The in-circuit emulator is described in an article entitled "Real-time emulation of 68000/68010 up to 20 MHz at highest is made possible by using a high speed RAM as a decoder" (in Japanese) published in a journal NIKKEI Electronics, No. 367, (Apr. 22, 1985), pp. 293-315.
It is possible to carry out a test under real use operating environments by connecting an emulator instead of a CPU in a target system.
An outline of the structure and the summary of operation of an emulator will be explained below, referring to FIG. 1. An emulator consists of a main part of emulator 4 and an emulation pod 1. Even if the CPU in the target system 8, which is to be emulated, is changed, it is not necessary to change the main part of the emulator. The emulation pod 1 is replaced in accordance to the CPU in the target system 8. An emulation CPU 3 executes a job in place of the CPU in the target system 8 and should be identical to the CPU in the target system 8. A timing circuit 2 generates a timing signal matching with the CPU 3. The main part of emulator 4 is composed of a control processor 7 controlling the whole emulator, a trace memory 6 storing signals coming from the emulation pod 1 and an event monitor 5 setting, supervising and detecting events.
Operations of such an emulator are to stop the execution of a program, when it proceeds to a certain address and read-out/rewrite the memory content at that time, to stop the execution, when read-out/rewrite data is in accordance with a particular values, and to execute instructions in a program one after another from a certain address, etc.
In an event monitor in an emulator as indicated in FIG. 2, occurrence of an event, which stops the execution of a program, can be defined only by a simple address and in the case where a software in a multi-process is tested, it is independent of which program is in operation.
FIG. 2 indicates an example of the construction of an event monitor effecting generation and supervision of an event in the emulator. Block 51 represents a simple event detector portion.
In the case where it is desired to interrupt the execution of a process (called "break point setting"), the condition for each of registers 37, 39 and 41 is set. A method setting a break point will be described. To define an event which occurs when a certain value is written in a certain address, if it is desired to generate an event, a desired address is set at the address register 37, a desired value is set at the data register 39 and W (Write) is set at the status register 41. Address, data and status information are supplied every moment from the emulation CPU 3 during the execution and they are compared with the values set by three comparators 38, 40 and 42, respectively. These comparators output "1", when they are in accordance with each other. When all of the address, the data and the status are in accordance with the respective values, the output of an AND gate 48 is "1", which indicates the occurrence of an event. Further, the comparators are so constructed that in the case where no conditions are set for the address register 37, the status register 39 or the data register 41, the corresponding comparator outputs "1" .
FIG. 3 is another example of the event monitor. According to this method, sequential events can be defined, that is, it is possible to set the device so as to confirm finally an event occurrence E.sub.F, only when a second event E.sub.2 (called post-event) occurs, after a first event E.sub.1 (called pre-event) has occurred. The event E.sub.1 is generated by an event detecting portion 51S having a structure similar to the simple event detecting portion 51 indicated in FIG. 2. Similarly to the detecting portion 51 the conditions for the event E.sub.1 are set in S registers 31, 33 and 35. The conditions for the event E.sub.2 are set in the simple event detecting portion 51. Here the prefix S means "Sequential" When the conditions for the event E.sub.1 are fulfilled the output of an AND gate 50 is "1"; the S (Set) input of the S event register 43 is "1"; and the E.sub.1 event occurrence is memorized. At this time the output of the S event register 43 is also "1". After that, when the event E.sub.2 occurs at the simple event detecting portion 51, the output of the AND gate 48 is "1". The output of the AND gate 49 is also "1", a sequential event occurs. Here the S event register is an R-S (Reset-Set) flipflop, in which the output is "1", when the S input is "1", this state being kept, until the R input is "1" and the state is reset.
Since, according to the method indicated in FIG. 2, the detection of the event is effected only by a combination of the address, the data and the status in the execution of a single program, if this method were used for a multi-process system as it is, it would give rise to a problem. In a multi-process system a plurality of programs are operated simultaneously (macroscopically). Its address space is indicated in FIG. 4. There are 3 processes A, B and C, each of which has an address space indicated by a thick line. Each of the processes has an independent process space and each of the processes A and C has an address X. The address X of the process A is completely different from the address X of the process C. On the other hand a system space is a space, which is regarded as the same by all the processes and in which a control program (operating system), data shared by different processes, etc. are stored.
It is supposed that, in such a situation, where a plurality of processes are operated, a break point is set at the address X of the process A. According to the method indicated in FIG. 2, since only the address X can be specified, even if the operator is informed of a fact that an event occurs at the address X, the operator cannot know which is operated, the process A or the process C.
According to the method indicated in FIG. 3, since a sequential event can be set, the system can be constructed so as to detect the commencement of a desired process as an event E.sub.1 in the event detecting portion 51S and the address, which should be the desired break point, as an event E.sub.2 in the event detecting portion 51. That is, the address, in which the process identification number of the process, which is currently being operated, is set in the S address register 31 (event detecting portion 51S); desired process identification information is set in the S data register 35; and W (Write) is set in the S status register 33. Additionally by setting address conditions, which defines the break point at the simple event detecting portion 51, it is possible to stop a desired address, when a certain process is operated (i.e. desired process identification information is stored in a particular address). However, there is a problem also in this case. That is, supposing that the event concerning the process identification information is E.sub.1 and the event concerning the break point address is E.sub.2, the desired E.sub.F is confirmed, only when E.sub.2 occurs after E.sub.1. According to the method indicated in FIG. 3, once E.sub.1 occurs, since it is not possible to reset the occurrence of the event E.sub.1 as far as an event monitor 5 is not reset, the following problem takes place.
This problem will be explained again, referring to FIG. 5, which is a diagram indicating mutual relations among the plurality of processes in FIG. 4 in a time series. Now it is supposed that it is desired to set a break point in the address X in the process A. The detecting portion 51S detects the occurrence of event E.sub.1 at t.sub.1, when the process A begins to run. Thereafter, if it is supposed that an execution process is turned over from A to C at t.sub.2 (called process switch) and that the address X occurs at a point of time t.sub.3, according to the method indicated in FIG. 3 an erroneous desired event E.sub.F occurs improperly at t.sub.3.